Enterprise customers typically maintain two types of database environments. First, relational databases are used in an On Line Transaction Processing (OLTP) environment to support transaction-oriented applications, like those developed by Dassault Systemes under the trademarks CATIA, ENOVIA, DELMIA, etc. Second, derived copies of the OLTP data are created for On Line Analytics Processing (OLAP), for value-add applications like business intelligence, reporting, and decision support. Historically OLAP environments also use relational database technology, but this is changing as storage systems tailored for OLAP use are becoming widely available. The Dassault Systemes brand Exalead® is an example of a modern OLAP repository.
Today, OLTP and OLAP environments are entirely disjoint, and applications are designed to support one environment or the other. The separation of these multiple database environments leads to suboptimal use of computing resources, duplication of effort, manual synchronization of data, and a host of other problems.
The following is in regards to art related to the combination of OLAP/OLTP systems. G. Danner, et al, in U.S. Pat. No. 7,756,822 present a federated view of OLAP/OLTP data. The disclosed system provides a combined view of content across OLAP and OLTP, where the data in each system is considered disjoint. Next Danner, et al. calculate this combined view by transforming contents of the OLTP system. Lastly, Danner, et al. provide an environment to support OLAP applications.
U.S. Pat. No. 7,743,015 by Schmitt is similar to U.S. Pat. No. 7,756,822. Schmitt focuses on building a consolidated data cube from OLAP and OLTP, starting with OLAP data and appending unsynchronized information from OLTP. There is no mention of data transformation (either implied or assumes single semantic). Schmitt provides an environment to support OLAP applications.
U.S. Pat. No. 6,480,842 by Agassi, et al. manages bi-directional relationships between data held in OLAP and OLTP. The Agassi et al, approach navigates from OLAP query results back to OLTP data, and navigates from OLTP query results back to OLAP data. Agassi, et al, does not present a combined view, instead they define a new class of OLAP application.
There is a need for leveraging both OLAP and OLTP environments from an application server that has significant transactional needs. An example of such an application server is ENOVIA V6 which provides an object modeling environment to application developers. The ENOVIA V6 object model supports authoring operations and assumes a highly concurrent multi-user environment, thus has strong needs for transactions and OLTP. However, many operations in ENOVIA V6 are read-only, and do not need transaction semantics, and thus applications could be handled more efficiently by an OLAP database server. It is highly desirable for the application developer to work from a single point of reference and let the application server decide which database server is appropriate for a given operation. However, there are no known programming frameworks (application servers) that provide transparent access to both OLAP and OLTP databases.
There are two main problems to be solved. The first is that the semantic level of the data in the OLAP and OLTP database servers may be different. The OLAP data is derived from OLTP data, but is typically altered somewhat by the Extract/Transform/Load (ELT) process that populates the OLAP database. Secondly, when accessing the OLAP database system, the framework (i.e. application server) must guarantee that any changes written on the OLTP database side have been synchronized with the OLAP database server. This guarantee is necessary to ensure the application has a consistent view of data across both database server environments.